Skip to content

Conversation

@julianlitz
Copy link
Collaborator

@julianlitz julianlitz commented Dec 20, 2025

Merge after: #141

Removes unnecessary MultiIndex and Point class. Cleans up the PolarGrid class and removes the slow unoptimized indexing.

Merge Request - GuideLine Checklist

Guideline to check code before resolve WIP and approval, respectively.
As many checkboxes as possible should be ticked.

Checks by code author:

Always to be checked:

  • There is at least one issue associated with the pull request.
  • New code adheres with the coding guidelines
  • No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

If functions were changed or functionality was added:

  • Tests for new functionality has been added
  • A local test was succesful

If new functionality was added:

  • There is appropriate documentation of your work. (use doxygen style comments)

If new third party software is used:

  • Did you pay attention to its license? Please remember to add it to the wiki after successful merging.

If new mathematical methods or epidemiological terms are used:

  • Are new methods referenced? Did you provide further documentation?

Checks by code reviewer(s):

  • Is the code clean of development artifacts e.g., unnecessary comments, prints, ...
  • The ticket goals for each associated issue are reached or problems are clearly addressed (i.e., a new issue was introduced).
  • There are appropriate unit tests and they pass.
  • The git history is clean and linearized for the merge request. All reviewers should squash commits and write a simple and meaningful commit message.
  • Coverage report for new code is acceptable.
  • No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

@codecov
Copy link

codecov bot commented Dec 20, 2025

Codecov Report

❌ Patch coverage is 94.44444% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 88.99%. Comparing base (6c8ca13) to head (9d472cd).

Files with missing lines Patch % Lines
include/PolarGrid/polargrid.inl 93.75% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #143      +/-   ##
==========================================
+ Coverage   88.21%   88.99%   +0.77%     
==========================================
  Files          89       87       -2     
  Lines        5246     5071     -175     
==========================================
- Hits         4628     4513     -115     
+ Misses        618      558      -60     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

*
*/

#define FINE_NODE_EXTRAPOLATED_PROLONGATION() \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be outside the scope of this PR but why are macros used here rather than static inline functions?

Copy link
Collaborator Author

@julianlitz julianlitz Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we should probably avoid these macros.
The reason I started using them was, that normal inlined function are slower than actual pasting in the code twice. But I haven't checked that in a while, so we could benchmark if using static inline does provide the same performance.

Comment on lines -13 to +7
namespace ExtrapolatedProlongationTest
static Vector<double> generate_random_sample_data(const PolarGrid& grid, unsigned int seed)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the static remove the need for the namespace?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible to either use the namespace or static to avoid the function collision caused by defining it in multiple .cpp files.
Here I switched to static since it is a bit shorter but the old namespace approach would also work.

Comment on lines -15 to +11
std::uniform_real_distribution<double> dist(-100.0, 100.0);
for (uint i = 0; i < vector.size(); ++i) {
vector[i] = dist(gen);
}
return vector;
std::uniform_real_distribution<double> dist(-20.0, 20.0);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you test on a narrower set of values now?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This changed because I rewrote the entire google test file (since prolongation0 is no longer available and we need a different test to verify the correctness).
Doesn't really matter what distribution we use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants